Skip to content

Conversation

@Nonanti
Copy link

@Nonanti Nonanti commented Aug 18, 2025

  • Add GitHub Actions workflow for automated releases
  • Support both manual trigger and tag-based releases
  • Publish to NuGet.org, GitHub Package Registry, and GitHub Releases
  • Add comprehensive documentation for the release process
  • Addresses issue Add a Release Pipeline #592

This pipeline will:

  1. Build and test all target frameworks
  2. Create NuGet packages
  3. Publish to NuGet.org (requires NUGET_API_KEY secret)
  4. Publish to GitHub Package Registry
  5. Create GitHub Release with attached packages

@Nonanti
Copy link
Author

Nonanti commented Aug 18, 2025

✅ Update: Release Pipeline is Working!

Great news! After analyzing the existing test workflows and understanding the build requirements, the release pipeline is now successfully working.

Test Results

  • Successful build: View workflow run
  • NuGet packages created: 14.9 MB artifacts generated
  • All stages passed: Build, test, and package creation

Key Changes Made

  1. Fixed MonoMod dependency: Set MonoModCoreVersion to 1.3.0 to use NuGet package instead of private submodule
  2. Removed submodule initialization: Avoided permission errors with private MonoMod repository
  3. Aligned with existing workflows: Used same build commands as test-build.yml
  4. Added proper environment variables: Included DOTNET_NOLOGO, etc. from existing workflows

Pipeline Features

  • ✅ Manual workflow dispatch with version input
  • ✅ Automatic trigger on version tags (v*.*.*)
  • ✅ NuGet.org publishing (requires NUGET_API_KEY secret)
  • ✅ GitHub Package Registry publishing
  • ✅ GitHub Releases with artifacts
  • ✅ Support for prerelease versions

Ready for Production

The pipeline is now ready to use. Once NUGET_API_KEY is added to repository secrets, it will automatically:

  1. Build and test the solution
  2. Create NuGet packages for all variants
  3. Publish to NuGet.org and GitHub Package Registry
  4. Create GitHub releases with changelogs

Looking forward to your review! The release process for Harmony can now be fully automated. 🚀

@pardeike
Copy link
Owner

  • For a automated release, I would prefer the common approach of not working on the main branch. I could simply not allow commiting to main and instead always require PRs. It's professionally anyway. This would simplify the release workflow.
  • Regarding the submodule: I always check it out, regardless if its used or not. Setting the MonoMod.Core version empty will automatically use the current git state of the sub repository. Otherwise it builds with the give nuget version, that's how the current build and test workflows do it and that's how the release workflow should work.
  • Tests need to pass or else we shall not release.
  • Your actions show a successful run on your fork but it has this part: "No files were found with the provided path: Harmony/bin/*.zip. No artifacts will be uploaded." - is that a real thing?
  • "Should the pipeline build all target frameworks or just specific ones for releases?" -> build a three: Lib.Harmony, Lib.Harmony.Thin and Lib.Harmony.Ref - and also upload them to nuget and put them all three zipped in the release page

Automated version management - that's an interesting question. I rather want to define the version in the dev branch somehow...
Are there any special build requirements or secrets needed beyond NUGET_API_KEY? No

@Nonanti Nonanti force-pushed the add-release-pipeline branch from 2788a10 to 985250e Compare August 19, 2025 00:59
@Nonanti
Copy link
Author

Nonanti commented Aug 20, 2025

i think its okey

@pardeike
Copy link
Owner

Can it be that the zip files/packages already exist after building? I think I don’t zip the nuget files but all the artifacts instead. Check against a manual build to see if there is a difference, or I can do that later when I have time. Also, remove comments mentioning me to keep it professional.

@pardeike
Copy link
Owner

Sorry for getting back to you so late but I had to deal with some illness. I think it would be nice to combine your work with this way to trigger it: https://chatgpt.com/share/68a88bfa-156c-8009-bd0b-ef1bf03898c7

What do you think?

@Nonanti
Copy link
Author

Nonanti commented Aug 23, 2025

@pardeike Thank you for sharing this approach! I really like the tag-driven
release strategy.

Key points I understood:

  • Use tags (v*) to trigger releases from master
  • Version source of truth stays in Directory.Build.props
  • Workflow validates tag matches HarmonyVersion
  • No extra branches needed

I'll update the PR to implement this approach:

  1. Add the release workflow with tag triggers
  2. Include version validation from Directory.Build.props
  3. Add the helper PowerShell script for tagging

This is indeed much cleaner and safer than branch-based releases. I'll get
this updated shortly

@Nonanti
Copy link
Author

Nonanti commented Aug 23, 2025

@pardeike Thank you for the feedback! I've updated the PR with a tag-driven
release approach as you suggested.

@Nonanti Nonanti force-pushed the add-release-pipeline branch 2 times, most recently from 58f2045 to 3d144f4 Compare August 23, 2025 15:00
@Nonanti
Copy link
Author

Nonanti commented Aug 23, 2025

@pardeike tested the workflow on my fork and it works:
https://github.com/Nonanti/Harmony/actions/runs/17176979461

everything passed except nuget publish (no api key on my fork obviously).
created this test release:
https://github.com/Nonanti/Harmony/releases/tag/v2.4.0.2

- Triggers on version tags (v*)
- Validates version against Directory.Build.props
- Builds and tests on all supported frameworks
- Creates GitHub releases with NuGet packages
- Publishes to NuGet.org (requires NUGET_API_KEY secret)
@Nonanti Nonanti force-pushed the add-release-pipeline branch from eb369db to 0805277 Compare August 23, 2025 15:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants